1. Technical Field
The present invention relates generally to computer network security and, in particular, to techniques for providing access to secured system resources within the context of an access control framework.
2. Description of the Related Art
Information technology (IT) systems and the Internet have fueled the growth of the current global economy. While IT systems have significant benefits, at the same time they pose potential security threats from unauthorized third parties. Indeed, the lack of security in modern IT systems has emerged as a threat to the integrity of global computer networks. To deal with this problem, IT systems provide a number of known services, such as data authentication, data confidentiality, entity authentication, and authorization. Data authentication typically consists of two sub-services: data integrity and data origin authentication. A data integrity service is used to convince a receiver of given data that the data was not changed during transit. Data origin authentication proves to the receiver the identity of the real sender. Data confidentiality protects against disclosure of data during transmission. Entity authentication provides the system with proof that a certain entity is who they claim to be. Authorization is the act of determining whether an authenticated entity has the right to execute an action. Authorization and authentication thus are related services. To be able to provide authorization, it is necessary to determine who the entity is (e.g., by entity authentication). Authorization, in general, consists of two separate stages: providing privileges (authorization credentials) to a particular entity, and using these privileges in combination with access decision rules at the resource to determine if access should be granted to the entity.
Many servers use an authorization system that has become outdated (such as The Open Group's Distributed Computing Environment, or “DCE”) and that does not make use of new authorization technology, such as role-based authorization and entitlements. The authorization system may also be dated because the application must use product-specific authorization APIs to access the authorization system. In contrast, The Open Group has promulgated a technical specification for a standard Authorization (AZN) API, Open Group Technical Standard C908, that can interface with any system or application that adheres to the standard.
New authorization systems are commercially available that make use of new authorization technology and standard authorization APIs. One example is IBM Policy Director. Developers of server applications desire to use such new authorization systems because they allow the server application to take advantage of new authorization technology and to plug in other authorization systems, as needed, that use the same standard authorization APIs. In the past, this has not been practical.
Upgrading a legacy application to the new authorization APIs can be both difficult and expensive. An effective solution requires extensive re-coding and testing of the legacy application, which is costly and may even be impossible if the required skills for modifying the legacy application are no longer readily available. Therefore, if the administrator of an enterprise needs to keep existing legacy applications, the administrator might not want to upgrade any of the applications to a new authorization system as this would require the administrator to support the databases used by both authorization systems.
For example, assume the administrator maintains an existing server application that is based on the DCE authorization system. This application would require the administrator to keep DCE interfaces on the server (which understands such calls as “dce_acl_is_client_authorized”) as well as the database used by the DCE-based authorization system. Now, assume the administrator wants to add a new server application that uses IBM Policy Director as the authorization system. This would require the administrator to maintain Policy Director interfaces as well as DCE interfaces to the server because both the calls to the standard authorization APIs and the DCE-based authorization system would need to be understood. Also, this would require the administrator to maintain the authorization databases required by both authorization systems.
Therefore, it would be advantageous to provide a methodology for plugging in a new authorization system without any changes to legacy applications.